一种新的架构设计思路，用户行为驱动开发

今日科技快讯

昨日上午微信部分功能出现短暂故障，微信用户登录、消息会话、公众号、小程序、外部链接、文件发送等功能均受到不同程度的影响，持续时间约30分钟。腾讯公关总监张军表示此次bug事件“感觉像是给攻城狮敲了一记醒神棒，哪怕快过年了也别想放松”。

作者简介

明天就是周六啦，提前祝大家周末愉快！

本篇来自 Android_ZzT 的投稿文章，分享了自己一种开发思想，希望对大家有所帮助！

Android_ZzT 的博客地址：

https://juejin.im/user/57c819d65bbb500074d9f217

前提

用户行为驱动开发是什么？

它是一种适用前端的面向用户行为的开发思想，是一个用户行为的产生到执行，驱动数据的产生，再由数据流驱动渲染的流程。我认为，前端要完成的工作就是接收用户行为，解析用户行为，到给用户一个反馈。在各种用户行为形成一个序列后，在之后的开发中可以得到很多方便。

用户行为驱动开发是如何诞生的？

由于每个 App 都需要采集数据进行分析，需要进行数据埋点，这些数据往往都是一个用户行为加上一些业务数据，如果使用代码埋点的方式，就会导致 UI 代码中总要掺杂着一些额外的埋点逻辑，比如一个 button 的 onClick 中有一段获取业务数据并发送埋点事件的代码，久而久之，代码就会变得臃肿不堪。现在虽然有无痕埋点的方案，但是成本过高，小公司去开发不是很现实。

出了上面的问题后，我意识到用户行为是一个关键点，其实每一个需要采集的数据都由一个或几个用户行为拼凑出来的，比如用户点击了登录按钮，其实就是由两个 Action 组成，ButtonClick 和 LoginAction。再比如，用户上拉加载更多数据，其实就是产生了 PullUpToLoadMore 和 GetXXXDataAction 。

带着这样的思考，我就开始尝试了面向用户行为开发。

其他说明

• 我是 Android 开发，之后的一些例子可能更适用于移动端，但思路上适合各种前端的

• 观察者（订阅\发布）模式，解耦利器，用户行为驱动开发使用了大量的观察者模式，让每一个部分职责单一明确

• 本文不讲代码的具体实现，只讲思想，之后可能会写其他的文章具体讲实现

正文

一、UserAction 的类型

如图，展示的是移动端的一些基本操作，左边四个是针对列表页面的操作，分别为「下拉刷新」「上拉加载更多」「Item 曝光」「Item 点击」。剩下四个为「PageView -> 浏览页面」「UseDomainService -> 使用业务服务」「 ButtonClick -> 按钮点击」「ComponentShowUp -> 组件展示」。

这里具体解释一下「使用业务服务」和「组件展示」

• 「使用业务服务」可以看做是用户在使用公司的业务，比如每个公司都会有登录注册，再比如公司中特殊的业务，如看视频或者获取一组新闻数据等

• 「组件展示」是指一个控件或组件弹出，比如 Android 中的 Dialog\Toast\PopupWindow 以及自定义的 Window 等

二、UserAction 驱动渲染的过程

首先说说，在一个简单的列表页中，UserAction 是怎样工作的

首先不考虑数据是怎么获得的，只想 UserAction 如何应用在 UI 代码中，就是图中的 5 个步骤。 UI 只负责生产对应的 UserAction，然后观察它，它在执行后会产生对应的结果，UI 只需要使用结果去渲染。

所以 UI 的职责很明确：

• 产生 UserAction

• 执行 UserAction

• 接收数据，进行渲染

UI 中的代码大概就像这样：

//页面开始显示一个列表
start() {
     observer = List<xxx> result -> { 
        render(result);
    }
    new GetXXXListAction().execute(observer);
}

//登录
loginBtn.setOnClickListener(v -> {
    ButtonClickAction btnClickAction = new ButtonClickAction();
    btnClickAction.enqueue();

    LoginAction loginAction = new LoginAction();
    loginAction.execute(observer, params);// observer 用于观察登录状态变化，参数为用户名密码
})

三、UseDomainAction 的执行过程

用户选择使用我们的 app，就是在使用我们提供的业务服务，所以业务逻辑处理是我们平时开发精力投放最多的一部分，我具体说一下「UseDomainService」是如何工作的。基于模块化开发，我们每个业务应该对一个模块，所以 action 执行时就是调用我们的业务模块的接口，这里针对业务模块的异步请求会再次使用观察者模式或是个 CallBack ，action 观察业务模块，然后接收模块返回的结果，再将结果发给执行 action 的页面。

下面是针对数据流向的一个图，可概括为UI -> Action -> Data -> ViewModel -> Render，UI 产生用户行为，用户行为驱动数据产生，数据驱动 UI 渲染

四、其他 UserAction 的使用方式

• 「PageView」：可在 LifecycleManager 的 onActivityResumed 方法中进行创建，然后取到每个 Activity 的路由 url 或是类名，存放到 PageViewAction 中。如果你有一个 BaseActivity，也可写在 BaseActivity 的 onResume 方法中

• 「PullDownToRefresh/PullUpToLoadMore」: 可在列表刷新控件的 callback 中，创建这个 Action，例如继承 SmartRefreshLayout 然后重写 refresh 和 loadMore 方法，在里面加上对应的 Action

• 「ButtonClick」：和上面👆类似，继承 Button，在 onClick 中，添加 ButtonClickAction

• 「ComponentShowUp」：也是继承基础控件，然后再 show 的时候添加这个 Action

• 「ItemImpression」：这个比较特殊，是列表中每个 item 曝光的行为，我的做法是在 RecyclerView 的OnChildAttachStateChangeListener 中的 onChildAttached 方法中记录，并且要绑定一些业务数据

这些 Action 在生成或执行时需要存放到一个列表里，形成一个序列，下一节会具体介绍。

五、UserActionSequence 用户行为序列

以下展示的是从开屏页，跳转到登录页，然后点了登录按钮的一个 UserActionSequence

假如数据需要我们在登录按钮处埋点，我们只需要从序列中找到对应的 Action 组成事件发到后端即可。当然后端最好也抽象出一些通用事件配合前端，那样用户序列的威力就会发挥到极致，基本可以在 UI 代码中做到无痕。下一节会简单说一下用户序列如何配合埋点系统做到基本无痕的埋点方式。

六、浅谈埋点

按职能解释「EventTracker」的每一部分：

• 「ProcessedActionBuffer」：
  需要观察 UserAction 入队，当有新 Action 入队时，就将其存到 ProcessedActionBuffer 中，并做一些特殊处理，比如「PageView」 我们是在 onResume 时生成的，但有时弹 Dialog 再回来的时候又会触发一次「PageView」（Android Activity 生命周期决定的，其他平台可能不会有这种问题），所以需要去重，保证发送没有冗余的数据给后端

• 「EventActionMapper」：
  用于映射 Action 和 Event，其实就是一套行为和事件的转换规则（需要前后端配合）

• 「EventBuffer」：
  存储转换过的 Event，有一套自己的策略进行缓存（例如大于100条存入本地数据库），还有一套策略用于发送（1分钟轮训一次 EventBuffer 进行发送）

图中还画了 Logger 和 Other 两个模块，Logger 可以根据行为序列记录一些日志，用于分析 Crash 和一些业务的异常，Other 大家就可以根据自己的脑洞和需要进行设计了，比如 UserActionSequence 是把 UserAction 序列化为 json 的过程，我们也可以把 json 反序列化成对象，然后再交给对应的 UI 去执行，这样就可以完成 UI 自动化测试。

总结

原来常使用的 MVP 或者最近比较火的 Android Architecture Component 使用的 MVVM，都不能很好的用代码来表示用户行为（代码可读性不够直观），虽然 Presenter 和 VM 的职能也是用来解释用户行为获取数据再到驱动渲染，但我觉得对于程序员来说还是不够友好。但使用 UserAction 来贯穿整个前端的流程，一切看起来就变得自然了，UI、模块、数据的职责也都显得更单一了。

重要的是这样开发是我们获得了用户的操作序列，一切的数据源于用户。有了它对以后的分析和其他的开发都会有很大帮助。